home *** CD-ROM | disk | FTP | other *** search
/ C/C++ Users Group Library 1996 July / C-C++ Users Group Library July 1996.iso / vol_100 / 122_01 / read.me < prev    next >
Text File  |  1985-08-19  |  7KB  |  208 lines
  1.    PISTOL - Portably Implemented STack Oriented Language
  2.                (Version 2.0)
  3.                  by
  4.              Ernest E. Bergmann
  5.              Physics, Bldg #16
  6.              Lehigh University
  7.             Bethlehem, Pa. 18015
  8.               (215-) 861-3932
  9.  
  10.     PISTOL 2.0 is being provided  essentially in the
  11. public domain, not because it isn't good, but to promote
  12. interest in "FORTH-like" languages.  It may be reproduced
  13. and distributed for commercial as well as personal use so
  14. long as the copyright notice is included. (Emulating the
  15. FORTH INTEREST GROUP ("FIG"), P.O. Box 1105, San Carlos, Ca.
  16. 94070)
  17.  
  18.     PISTOL 1.3 was previously released about a year ago
  19. as SIG/M volume 59 and, also, through the BDS 'C' Users'
  20. Group.  An article on PISTOL appeared in the February 1983
  21. issue of Dr. Dobb's Journal.  Additional examples and
  22. documentation on PISTOL are to be found in the earlier
  23. release.
  24.  
  25.     The development of PISTOL is based largely upon STOIC
  26. (STack Oriented Incremental Compiler) that was developed by the
  27. MIT and Harvard Bio-engineering Center in 1977.  STOIC is
  28. readily available from the CP/M User's Group as Volume 23A.
  29.  
  30.     PISTOL was developed with a different philosophy,
  31. perhaps, than its predecessors, FORTH and STOIC.  It is my
  32. belief that FORTH-like languages should be available to users
  33. of large mainframe machines as well as mini- and micro- users.
  34. I have concentrated upon the following goals.  User
  35. friendliness, Portability between machines with different word-
  36. lengths and machine instruction sets, and KISS ("Keep it simple
  37. stupid"), free of many of the ideosyncrasies that have
  38. irritated me with FORTH and, to a lesser degree, STOIC.
  39. Lastly, I wanted PISTOL to be as self-contained and complete as
  40. possible (and my endurance!).  Obviously, the result is not as
  41. chintzy about RAM and file space as its predecessors.
  42.  
  43.     Before the FORTH enthusiast is discouraged from
  44. examining this language further, I hasten to add that there are
  45. a number of simplifications that I have introduced which might
  46. be worth considering.  I shall now detail some of the ways that
  47. PISTOL differs from classic FORTH.
  48.  
  49.     Following the lead of STOIC, PISTOL supports strings as
  50. a fundamental element of the language.  They are manipulated in
  51. almost the same manner and ease as numbers.  For example, to
  52. define a word, "DEMO", FORTH starts off with:
  53.  
  54.     : DEMO . . .
  55.  
  56. wheras STOIC and PISTOL start off with:
  57.  
  58.     'DEMO : . . .
  59.  
  60. This could be very important if the choice of name is to be
  61. flexible.  How would one write in FORTH the definition for "3"
  62. depending upon whether the constant "FRENCH" were true or not?:
  63.  
  64. FRENCH IF
  65.     'TROIS
  66.     ELSE
  67.     'THREE
  68.     THEN : 3 ;
  69.  
  70.     Again, following the lead of STOIC, we compile
  71. everything into a compile buffer.  Thus there is no interpret
  72. mode as in FORTH.  This change simplifies the language because
  73. we don't have to code two distinct modes and provide two
  74. separate sets of rules.  To illustrate this point:
  75.  
  76. 20 0 DO <whatever> LOOP
  77.  
  78. would work just fine typed in for immediate execution;  it does
  79. NOT have to be embedded in a definition!
  80.  
  81.     We differ from STOIC and early forms of FORTH by
  82. storing the complete name of each definition.  STOIC, for
  83. example, saves only the first five letters (and a letter
  84. count).  We found that it simplifies coding the language
  85. originally, the variable length of the name might actually
  86. take no more space, and, most importantly, when we use the
  87. dissassembler and the trace features of PISTOL, we see the
  88. full, original names of the words used.
  89.  
  90.     We have "packaged" PISTOL so that the disassembler,
  91. trace, and editor are always resident (they probably could be
  92. removed, but why not enjoy the synergism of the complete
  93. environment at your fingertips!)
  94.  
  95.     The prompt is much more informative than in other
  96. languages.  STOIC started this trend by displaying "nesting
  97. depth" we have continued this trend by displaying the number of
  98. elements on the parameter stack when it is not empty.  The
  99. prompt explicity shows the current number base being used.  If
  100. the nesting depth is not zero, one sees what one is "nested
  101. into".  This information is used also for more viligent syntax
  102. checking.  I have worked with the earlier languages that
  103. fatally "bomb" with such lines as:
  104.  
  105. IF . . ;
  106.  
  107. or
  108.  
  109. DO . . THEN
  110.  
  111.     We have been able to remove the "arbitrary" restriction
  112. that a ": ...;" definition can only be made at level 0.  We can
  113. and do make extensive use of definitions that are nested inside
  114. of conditional expressions or, even, inside of other
  115. definitions!
  116.  
  117.     We do not support "CODE" definitions in the present
  118. "vanilla PISTOL".  Here are our justifications:  We wish to
  119. guarantee portability of source code between widely
  120. differing machines.  In addition, we wish to maintain our
  121. goal of user friendliness by being able to disassemble
  122. virtually everything.  Obviously we depart from STOIC
  123. particularly on this point, but STOIC is not portable to
  124. non-8080 compatible machines.
  125.  
  126.     Because the primitives of PISTOL are defined in some
  127. high level language, such as PASCAL or C, it is expected that
  128. additional primitives might be added to the "kernel" as the
  129. need arose.  For example, in order to increase the speed of
  130. PISTOL for block move operations in editing we might want to
  131. replace LDDR, a slow, PISTOL language definition.  On a Z80
  132. machine there is an obvious machine hardware instruction that
  133. could be used instead.  One could add this word to the KERNEL
  134. and "generalize" PBASE be replacing:
  135.  
  136. 'LDDR : . . .
  137.  
  138. by
  139.  
  140. 'LDDR DUP FIND IF
  141.         DROP
  142.            ELSE
  143.         : . . .
  144.            THEN
  145.  
  146.     To slightly ameliorate the lack of "CODE" definitions
  147. we have provided an "inline macro" facility.  If one creates a
  148. word definition using:
  149.  
  150. $: . . . ;$
  151.  
  152. instead of:
  153.  
  154. : . . . ;
  155.  
  156. then when the word is invoken the contents of the definition
  157. are compiled into the compile buffer instead of a "call" to the
  158. definition.
  159.  
  160.     A number of conveniences are provided which are not
  161. common to the "competition".  The crude line editor that is
  162. provided with PISTOL can be used in a BASIC-like fashion.
  163. In addition to being able to "LOAD" files, one can "LOAD" the
  164. edit buffer as well, starting at any particular line number.
  165. For example:
  166.  
  167. 'MYWORK.PIS LOAD
  168.  
  169. and
  170.  
  171. 3 LOAD
  172.  
  173.     There are times when it is nice to record the terminal
  174. session.  Instead of using a printer one can create a disk file
  175. that will hold the record:
  176.  
  177. 'XYZ LISTFILE
  178. LIST ON
  179. .
  180. .    <this will be recorded>
  181. .
  182. LIST OFF
  183. .
  184. .    <this will not>
  185. .
  186. LIST ON
  187. .
  188. .    <this will>
  189. etc.
  190. .
  191. .
  192. BYE    <this way of exiting PISTOL will properly close
  193.      all files that are openned for writing>
  194.  
  195.     Undoubtedly, there are other important differences that
  196. I have not discussed;  I hope that you will give PISTOL a try.
  197. I would be most pleased to receive you comments, constructive
  198. criticisms, and questions.
  199.  
  200.  
  201.                     March 3, 1982
  202.                     
  203.                     Ernest E. Bergmann
  204.  the
  205. definition.
  206.  
  207.     A number of conveniences are provided which are not
  208. com